Gorkem Ercan

A conference for Eclipse heads

2016-12-06T15:51:00.001-05:00

Since, the first EclipseCon in 2004, that was held in Disneyland, Eclipse had a conference in US. I missed all the Disney music of 2004 and my first EclipseCon was in 2005 but I have presented on various EclipseCons since then. Throughout these years, I was able to observe the variances on interests for EclipseCon audiences. However it is a challenge to form an EclipseCon program that is equally interesting to developers of Eclipse technology and Eclipse users. This year the job had become a bit easier, to serve varying interests EclipseCon is teaming up with Devoxx US and becoming Eclipse Converge.

As part of the program committee for Eclipse Converge, my goal is to shape a program in the spirit of the early EclipseCons where the talks would be concentrated around building and innovating on Eclipse projects. If you have talks that are deep in Eclipse technology, please submit them. At least I will be voting for them.

And who knows we can bring the Disney music back to EclipseCon next year!

Benchmarking JavaScript parsers for Eclipse JSDT

2015-11-17T13:36:00.001-05:00

The JavaScript parser for the Eclipse JSDT project is outdated. It lacks support for the latest EcmaScript 2015 (ES6) standard and has quality issues. Moreover, the parser on JSDT is derived from the JDT’s Java parser, hence it is not adopted by the JavaScript community at large, leaving the JSDT committers as the sole maintainer. Luckily, there are good quality JavaScript parsers that already support a large number of tools built around it. However, these parsers, like most of the JavaScript tools, are developed using JavaScript and requires additional effort to integrate with Eclipse JSDT which runs on a Java VM. In the last few weeks, I have been experimenting with alternatives that enables such integration.

Parsers

Before I go into the details of integration let me quickly introduce the parsers that I have tried.

Acorn	Acorn is a tiny parser written in JavaScript that supports the latest ES6 standard. It is one of the most adopted parsers and used by several popular JavaScript tools. It parses JavaScript to ESTree (SpiderMonkey) AST format and is extensible to support additional languages such as JSX, QML etc.
Esprima	Esprima is also a fast, tiny parser that is written in JavaScript, which also supports the latest ES6. Its development has been recently moved to JQuery foundation and has been in use on Eclipse Orion for a while. Just like Acorn it also uses the ESTree AST format.
Shift(java)	Shift(java) is the only Java based parser on my list. It is a relatively new parser. It uses Shift AST as its model which is different from the widely adopted ESTree.

Note

Why does AST model matter?

AST model is what actually what tools operate on. For instance a JavaScript linter first uses a parser to generate an AST model and operates on the model to find possible problems. As one can imagine, an IDE that uses a widely adopted AST model can utilize the ecosystem of JavaScript tools more efficiently.

Eclipse JSDT already comes with a JSDT AST model that is used internally that is very hard to replace. Therefore, regardless of the AST model generated by the parser it will be converted to JSDT’s own model before used. Which renders discussions around the AST models moot in JSDT’s context.

Integration

The parsers other than Shift, which already runs on the Java VM, need a mechanism to play nice with the Java VM. I have experimented with 3 mechanisms for running Acorn and Esprima for JSDT so far.

Node.js	Utilizes node.js to run the parser code. node.js runs as an external process, receives the content to be parsed and return the results. I have chosen to use console I/O to communicate between node.js and Java VM. There are also other techniques such as running an http or a socket based server for communication. In order to avoid the start up time for node.js, which does affect the performance significantly, node.js process is actually kept running.
J2V8	A JNI based wrapper that bundles V8 JavaScript VM. It provides a low level Java API to execute JavaScript on bare V8 engine. Although it uses V8, it does not provide the full functionality of node.js and can only be used to execute selected scripts, fortunately Acorn and Esprima parsers can be run with J2V8.
Nashorn	The JavaScript engine that is nowadays built into Java 8. Provides a simple high level API to run JavaScript.

Performance Benchmarks

The criteria for choosing a parser may vary from the feature set, to AST model used, to even community size. However performance is the one criteria that would make all others relevant. So in order to compare the performance of different alternatives I have developed a number of benchmark tests to compare parsers and the mechanisms.

All benchmark tests produce a result with an AST model, either in JSON form or as a Java object model. Tests avoid the startup time for their environments, for instance the startup time for the node.js process affects the results significantly but are discarded by the tests. The current test sets use AngularJs 1.2.5 and JQuery Mobile 1.4.2 (JQM) as the JavaScript code to be parsed.

Table 1. Average time for each benchmark
Parser(Script)	Runtime	Score	Error
Acorn (AngularJS)	J2V8	118.229 ms	± 1.453
Acorn (JQM)	J2V8	150.250 ms	± 4.579
Acorn (AngularJS)	Nashorn	181.617 ms	± 6.421
Acorn (JQM)	Nashorn	177.265 ms	± 9.074
Acorn (AngularJS)	NodeJS	59.115 ms	± 0.698
Acorn (JQM)	NodeJS	34.670 ms	± 0.250
Esprima (AngularJS)	J2V8	98.399 ms	± 0.77
Esprima (JQM)	J2V8	114.753 ms	± 1.007
Esprima (AngularJS)	Nashorn	73.542 ms	± 0.450
Esprima (JQM)	Nashorn	73.848 ms	± 0.885
Shift (Angular)	JavaVM	16.369 ms	± 1.019
Shift (JQM)	JavaVM	15.900 ms	± 0.325

As expected Shift parser which runs directly on top of JavaVM is the quickest solution. To be fair, Shift parser is missing several features such as source location, tolerant parsing and comments that may affect the parsing performance. However even after these features added it may remain the quickest. I feel that the performance for J2V8 can also improve with more creative use of the low level APIs however there is so much memory copying between Java heap to JNI to V8 heap and back I am not sure if it would be significant.

The surprise for me is the Esprima’s performance with Nashorn. It is unexpected in two ways. It is actually the third quickest option however Acorn does not give the same level of performance.

What is new on Eclipse Thym 0.2.0

2015-03-20T11:25:00.000-04:00

We have just released a new version of Eclipse Thym.

Compared to 0.1.0 release the highlights for the 0.2.0 release are.

Working sets are supported on New Hybrid Mobile Project wizard: You can add your Hybrid Mobile projects to JavaScript working sets during project creation.
Convert existing Eclipse projects to a Hybrid Mobile project: Any existing Eclipse project, that has a proper config.xml and www directory, can be converted using the Configure > Convert to Hybrid Mobile Project menu item. This feature also introduces a new API to enable adopters to programmatically convert existing projects to Hybrid Mobile projects.
Icon and Splash Screen support for iOS and Android builds: If your config.xml has icon and/or splash screen references. Native project or executable exports created from Thym will honour them. Refer to Apache Cordova documentation for details of icon and splash screen support.

As usual Thym 0.2.0 is available from these update sites and Eclipse marketplace.

Update existing installs:

http://download.eclipse.org/thym/releases/latest/

Release repository good for building against:

http://download.eclipse.org/thym/releases/0.2.0/

Adoption... Sort of

2014-07-14T21:57:00.000-04:00

Apparently, myeclipse has started to use bits and pieces from Thym. It was brought to my attention that the plugin wizard image on the myeclipse feature page is from Thym. You can compare it with an image of the same wizard on JBoss tools features page for yourself. I have not tried the product myself hopefully it is working well.

Normally, I would be very excited about a product adoption happening this quickly. However, the folks behind this product have a different way of adopting open source software, which usually means project Thym will get zero benefits from this adoption. Of course, one can only hope for a positive surprise.

Sharing Cordova projects becomes easier

2014-06-10T11:59:00.000-04:00

Whether a project is created using Cordova's CLI or the Eclipse Thym (or JBoss Tools) sharing Cordova projects within a team is unpleasant. Cordova projects include generated artifacts and binary files in their source tree which violates source code management (SCM) best practices.

The first set of generated files are on the {$PROJECT_ROOT}/platforms directory. When using Cordova CLI when a cordova platform add {$PLATFORM} command is issued on a project, a {PROJECT_ROOT}/platforms/{$PLATFORM} directory is generated. This directory contains all your artifacts from {$PROJECT_ROOT}/www, {$PROJECT_ROOT}/merges/{$PLATFORM} directories and all the files necessary to create a native application with the platform build tools. Fortunately, Eclipse Thym generates platform folders on a temporary location and only when needed, hence does not share this problem. When using SCM tools, {$PROJECT_ROOT}/platforms should not be added to source management. For long term sanity, developers should do the extra step when they get the code from SCM and issue "platform add" commands for the platforms that they will work on.

The {$PLATFORM_ROOT}/plugins folder includes the files for Cordova plugins installed to the project. These files are not usually modified by the developers but installed with the cordova plugin add {$PLUGIN_ID} command. This command creates a {$PLATFORM_ROOT}/plugins/{$PLUGIN_ID} directory and copies the plugin's files in. Eclipse Thym also does a similar thing but it uses a filter on the project explorer so that the files do not confuse developers. Since these files can be regenerated and are not modified during daily development, it is a bad practice to add them to the SCM tools. Because both Cordova CLI and Eclipse Thym did not have a record of installed plugins other than the directories under {$PLATFORM_ROOT}/plugins/ directory, it was not possible to avoid adding them to SCM.

Recently, I have added a couple of new commands to Cordova CLI. cordova save plugins saves the list of currently installed plugins to config.xml. cordova restore plugins reads these entries from config.xml and restores them to the project. The save command also comes with a --shrinkwrap flag to freeze to the installed versions of the plugins. Of course, Eclipse Thym also implements this feature. Here is a demo that shows the feature at work.

With the new save and restore commands and its implementation on Eclipse Thym, it is considerably easier to share Cordova projects but we are not done yet. At this time, restore and save commands support restoring plugins only from Cordova plugin registry but support for more sources should be expected in the future. It is also planned to extend these commands to platforms.

UPDATE: The commands and the functionality has evolved since the original post. Please refer to Cordova platform and plugin version management guide for the latest.

Eclipse is changing and that is a good thing

2014-03-31T22:19:00.000-04:00

After missing a few years, I have attended the EclipseCon NA 2014 this year. I am not sure if it is because I missed a few of these but I felt a deep change in Eclipse. I think the change roots from the fact that Eclipse foundation nowadays, has almost no restrictions on the type of projects that it hosts. I am not sure when this was actually relaxed. Back in the day, it was required that all Eclipse projects to use OSGi as runtime, hence be developed with Java. Nowadays, any project regardless of the runtime, development language is welcomed as long as it agrees to adhere to eclipse way. I believe this has triggered a slow shift on Eclipse from being a tooling community to a larger scoped open source community. I expect to see this change to accelerate in coming years as Eclipse's perception as a tooling only community slowly fades.

Looking at the interest and attendance from project committers, I am sad to report that Eclipse WTP project is terminal. There are a couple of reasons why an important project such as WTP is not dead yet. First, it has a large user community as indicated by download numbers. Also, it has a lot of commercial, and open source products that depend on WTP or parts of WTP. One would imagine that this dependency would create a lot of contributions to upstream. However, most of these products, for one reason or another, prefer to build around WTP and not contribute. I do not think we will be seeing new features on WTP anytime soon if ever.

I did receive a good amount of attention to my Hybrid Mobile development talk and the new Thym project proposal. I have started listing some of the interested parties to the proposal. And also was able to recruit Doug Schaefer and Chris Aniszczyk as mentors to the project. If you would like to be listed as an interested party and show your support, it is not late, please do let me know.

I am continuing my great open source community conferences tour with ApacheCon. It will be my first one, so I am not sure about what to expect. I will be speaking about building Cordova applications with Eclipse IDE on Tuesday. April 8, which should be fun.

Talking About Cordova Tooling and Thym Project Proposal

2014-03-12T00:55:00.000-04:00

This spring turning out to be the season for conference sessions for me. I will be speaking about the new Hybrid (ehh... well Cordova) development tools on three different conferences.

The series starts with EclipseCon next week. My "Hybrid Mobile Development Tools for Eclipse" session will be on Tuesday, March 18, 2014 between 13:30-14:05.

Also, we had a recent proposal to move the development of most of the JBoss Hybrid Mobile tools to Eclipse. This will give me a chance to discuss anyone who is interested on Hybrid Mobile tooling for Eclipse and get the project going possibly faster. If you are attending and would like to discuss please let me know or just find me at the conference.

Multiple Cordova Engines on JBoss Hybrid Mobile Tools

2014-01-09T13:16:00.000-05:00

Until this week, JBoss Hybrid Mobile Tools were able to work with a single Cordova version. To add insult to injury that single version (which is Cordova 3.1.0) was embedded in and was not changeable. However, Santa was busy and just dropped an initial implementation of multiple Cordova engine support to nightly builds. Below is a video of it in action. If you are cool enough to get the nightlies, instructions are on the project's site .

A word of caution is needed though. This feature is still under development. If you really really need to use a different cordova version it will do the trick but for anything else I would wait for the release before moving my production code. Please do try the feature and provide feedback either on the related issue or create new ones.

Not even a year

2013-12-12T22:42:00.000-05:00

Within the past 12 months, I had a baby boy, moved to a new country, changed my job and developed a set of Eclipse plug-ins for developing Cordova applications.

The Hybrid Mobile development tools, as I called it, is about to be released as part of the JBoss Tools 4.1.1 release. Below is a video overview of the main feature set that is available in this release.

We have a good set of features implemented but we are not done yet. Please do use the tools and provide your feedback on the current feature set and future ones. If you feel like making some changes you can fork the project on github.

In the mean time, we have started to explore if Eclipse Foundation would be a good place to further expand the development of the project. I am also interested to hear thoughts on that as well.

Exporting on JBoss Hybrid Mobile Tools

2013-07-29T14:00:00.001-04:00

Work that I have been doing on tools around Apache Cordova is continuing its progress. I have been aware that we were not doing such a great job with exporting stuff out of our new project type, Native Hybrid projects. So I have been working to build a couple of new export wizards to fix this problem. Overall the development of the wizards have taken a longer time then usual because I decided to introduce extension points to accommodate easier integration of platforms in addition to currently supported iOS and Android. More on the extension points later as it deserves a post of its own.

The first of the wizards allows developers to export Native Platform Projects. Basically it generates a native project with all the bits from Apache Cordova for that platform that you can open/build/run via the platform's tools. For example, on iOS the exported project is an XCode project that can be build/run using XCode. Here is a screencast that shows export Native Platform Project wizard in action.

The second wizard is Mobile Application Export wizard. It helps you to export a native platform binary that is build for release. Depending on the platform, you can run this binary on a real device directly or after signing. At this time, we do not sign the binaries, but I do wish to support it in the future. I think this will be a critical feature if/when we support remote compilers.

We are moving as (reasonably) fast as possible to add new features to the project so project is actually on that exciting stage to contribute. If you are interested, it is hosted on github and your pull requests are always welcome. If you feel the need to contact me, you can use the JBoss tools mailing list or the #aerogear or #jbosstools irc channels on freenode.

A new IDE based on Eclipse MTJ

2012-06-26T09:30:00.000-04:00

Nokia released a new version of the Nokia SDK for Java. In additon to supporting AshaTouch devices (devices with touch only input for you and me ), it includes a new IDE. This new IDE is based on Eclipse MTJ. For those who remember, it also integrates to SDK discovery features of the now discontinued Pulsar distribution of Eclipse.

The main focus on this version of the IDE was to make it easier for newbies to Nokia platforms to discover and install the necessary tools and get started. On the discovery part IDE does a good job. As you can see from the screenshot it provides an extensive array of filters to find the right SDK for your project.

You should expect to see more features coming to the IDE and some of them will also appear on MTJ.

Besides the fact that I am the project lead for the Eclipse MTJ, this IDE makes me happy for an additional reason. I believe this is a product of my internal evangelism that has taken years to build up. For those of you who have not worked for the large companies (lucky you) this may sound strange. But large corporations are like a community of their own and you basically spend more time advocating to your company than outside your company.

In this case, I had a positive result but in evangelism you encounter more frustrations than victories.

MTJ release 1.1.2 is available

2011-03-09T08:35:00.000-05:00

Together with the rest of the Eclipse Helios SR2 release, MTJ project has also made its 1.1.2 release available. Unlike most Eclipse projects MTJ project introduces new features on SR releases as well. You can find the information on the new features in the new & noteworthy page. Equally important to the features is the list of the bugs that were fixed in this release.

Please note that MTJ project recently had a project move. As part of the move, the URL for its web site has been changed to http://www.eclipse.org/mtj the changes have also affected the update sites and the download sites and the /dsdp/ has been removed from them. Project team has updated the website and all the references that we are aware of, however if you notice that some link has been missed and is still pointing to the old URLs please report them.

My boss asked me to use Orbit UI and I said No

2010-10-21T18:17:00.003-04:00

You may have heard the announcements from Nokia that "Nokia Focuses on Qt to Extend Reach for Developers". This sentence actually does not make sense to those who are not familiar with the matter. Why should it? One would assume that Nokia, which acquired Trolltech -the maker of Qt- and became the maker of Qt, would be using Qt for all its internal and external development needs. Well, one would be wrong.

At the time, when Nokia acquired Qt, Nokia was in immediate need for a good looking, finger touch enabled UI toolkit with a complete API set. There were already efforts within Symbian organization to create a solution. This effort was fairly resourced and did have limited success. However, this solution did not really provide the ease of development, or a complete API set and we all know that getting those right requires a lot of work. As a result, Nokia did the best acquisitions of its history.

When Qt arrived to Symbian, it did not have a look and feel suitable for mobile. It was using its default windows style and on a phone that actually looked horrible. This alerted the people who are responsible of the welfare of the Symbian's UIs. Since the former employees of the Trolltech were still probies on Nokia, they turned to the only people they knew for a solution. More or less the same group of people that tried to provide the earlier solution started to build a UI toolkit using mainly the basic graphics capabilities of Qt. The resulting work was later named Orbit UI.

Orbit was so dominant on Symbian organization that Orbit was synonymous to Qt. I recall explaining over and over to people the difference between Orbit and Qt back then. It was actually around those days when my boss.probably affected by the propaganda and the amount of resources put behind Orbit, asked if we should start using Orbit to implement Java UIs instead of Qt. My reply was, "No, we are better of with Qt".
I have steered away from Orbit for several reasons, its cross-platform story was unclear, Orbit development team did not have a history of making good APIs, it was missing functionality that was important to implement eSWT. More important from all these. Orbit was the result of human factors and did not provide a superior solution to a technical problem. Hence, It is not amusing that Orbit UI and its sister MeeGo touch (which also has a similar story) now vanishes and Qt and the new Qt Quick becomes the main developer focus for Nokia's internal and external developers. Now, Nokia's developer story becomes one that I can trust to have the eSWT implementation on.

Update: The good folks on Forum Nokia has informed me about MeeGo touch. Appearently, MeeGo touch is not going away immediately in Harmattan, however it is not the recommended UI toolkit.

New MTJ release available

2010-09-27T08:58:00.000-04:00

Slowly but surely Eclipse Mobile Tools for Java (MTJ) project continues to improve. In coordination with the Eclipse Helios SR1 release, we had the MTJ 1.1.1 release.

If you have received MTJ through Pulsar package, you can receive your update for the new release from within Eclipse using Help->Check for Updates. Pulsar SR1 release can be installed from here. MTJ 1.1.1 is also available as a separate download and update site as well.

This is a bug fix release, notably it fixes the bug 312045 which was causing problems on the preverifier builder for some. Also improved is the Javadoc detection for most SDKs. The complete list of bugs fixed in the release is here, and the new & noteworthy has some details on the SDK detection. I am particularly happy about the improvement this feature brings to MTJs use with the Nokia Symbian SDKs.

A Numberic Retrospective of Pulsar Galielo release

2010-06-19T06:47:00.000-04:00

Now that Eclipse Helios is just around the corner, and the hectic days of getting the release ready is over, I thought this would be a good time to look back at what was achieved on the very first Pulsar release. Predictably, I took a moment to harvest the download statistics of the Eclipse Pulsar Galielo simultaneous release to come up with some numbers that are easier to consume.

If you are not familiar with the download statistics of Eclipse, these numbers represent the downloads that went through the Eclipse.org infrastructure. That means, if you have downloaded Pulsar directly from a mirror site without the mirror redirection from eclipse.org, your download is not counted in these numbers. Unfortunately, these numbers do not include the p2 installs and updates either, because Pulsar did not enable p2 download statistics on Galileo release. This is something we are fixing on Helios.

Here is some notes about the Pulsar. Eclipse's mobile development packaging is called Pulsar. On Galielo release it provided mainly the tools for MIDP development. So it is safe to assume that these download numbers reflect mostly an audience of MIDP developers. Eclipse Mobile Tools for Java (MTJ) is the project that produces the development tools for JavaME development. Although the main distribution of MTJ is through Pulsar, MTJ also produces downloads that are independent from Pulsar. The downloads for MTJ’s direct downloads are not part of this report and the MTJ 1.0.1 release did receive an additional download of 18927 to date.

As you can see from the above numbers win32 is by far the most popular development platform for Pulsar. It is probably even more so than other Eclipse packages because the platforms supported by the mobile emulators are still limited. Also you will notice a drop on the number of downloads between SR1 and SR2 release. I guess, without any evidence, this is because many of the SR1 users updated through P2.

A look at the top 10 countries for the downloads reveals that a huge majority of the Pulsar users are from China. I was expecting to see China as the top country but the gap between China and other countries really surprised me.

The overall numbers indicate that despite all the excitement around the Android, iPhone application development, MIDP still has one of the largest mobile developer community on earth.

Pulsar's first year reach performance seems to be quite satisfactory. I expect a slightly better reach with the Helios release because Pulsar is better known by developers this year. I do not expect a big jump though because Pulsar does not yet provide a well integrated solution for mobile development other than MIDP.

No OSGi on your phone

2010-05-28T06:50:00.000-04:00

OSGi was initially created for mobile and embedded world. I think it is the dream of an every OSGi geek dream to develop applications. for a cool OSGi engine that is bolted together with the operating system of your phone. An OSGi phone that would provide access to everything your phone can do together with all the goodness that comes from OSGi. A dream phone that would allow you to bring in your OSGi service that integrates with your cloud service, over the air when declared as dependency. Although, OSGI had a few attempts to really break into mobile phone world it is unfortunate that OSGi phone will remain a dreams for foreseeable future.

Nokia did work on an OSGi based Java environment for Symbian phones. Nokia even went to the trouble to create a JSR for it. It established a pretty ambitious R&D program around OSGi. It was actually these ambitious goals that eventually caused it to fail. The R&D program was ambitious because it not only promised to provide OSGi but it also tried to get Midlets to work together with the OSGi engine. However, OSGi aware midlets model especially the MIDP security did not fit to OSGi and the R&D effort was never able to deliver a solution that was acceptable. In my personal opinion the main flaw was on the effort was treating OSGi as another runtime on the device rather than the main engine.

Most of the effort did not get wasted on Nokia's effort though. On the older MIDP environment all the pieces of the Java environment (all JSR implementation etc..) was compiled into a single binary together with the VM and was loaded together with it. OSGi model required a flexible architecture so almost all the pieces of the Java environment was re-designed for it so that they would be separate libraries consisting of a jar and possibly a native dll. These pieces are compiled separately and are loaded on demand by VM. This architecture later converted into MIDP environment as well. The Java environment of S60 3.2 and later devices and the Java environment currently available as part of the Open source Symbian foundation code carries this architecture. A few advanced APIs such as eSWT was also created in this era.

A second opportunity was when Google started working on Android. The goals of the Android was almost a perfect match with OSGi. And this time OSGi would be the engine that runs all the services and applications of the phone which lacked on the earlier Nokia attempt. It is also known that there were members of the Android team who did know well about OSGi. It is hard to know as an outsider what really went but Android did not use OSGi and build its own version of concepts to provide similar functionality.

Although there were later attempts like the Sprint Titan platform to bring OSGi to mobile phones, they also failed when the smartphone market changed rapidly to different directions. Unfortunately, in the current climate it looks very unlikely that anyone will bother to spend the time and energy to make OSGi part of mobile phones.

Changes on this blog's Planet Eclipse participation

2010-05-03T06:37:00.000-04:00

If you have been following this blog through Planet Eclipse, you should be aware that the full content of this blog will no longer be available on Planet Eclipse. This blog started its life with the intention to provide information and updates around the Eclipse projects I am involved with and grew from there. Lately, the developments on technologies that I am working with and interested in are more frequently outside the scope of Eclipse. Since I want to blog about mobile and web software technology happening outside Eclipse and out of respect to the Planet Eclipse readers, I am replacing my feed on Planet Eclipse with one that carries only posts labeled for Eclipse. If you are a Planet Eclipse reader but still would like to read all the posts, you can subscribe to the full feed.

Threading on Symbian eSWT

2010-04-19T08:33:00.000-04:00

eSWT, just like SWT, implements a single threaded UI model (single-threaded apartment model). And just like SWT it provides access to UI functions from this thread only. This does not mean that you can have only a single thread on eSWT/SWT applications it means that the GUI interaction is exclusive to a designated thread. You can read more about SWT threading model in SWT FAQ. In this post, I will compare the implementation details of this model on eSWT port for Symbian and the new Qt port.

Avkon UI, that is used to implement the S60 port of eSWT, also have similar restrictions on threads. So one would think that eSWT S60 port just wraps the native Symbian UI thread since we have matching behavior. However, this is not the case with the S60 eSWT port. eSWT on Symbian actually creates two threads. Thread one runs the Symbian's UI environment which within the team we refer as the native UI thread. Thread two runs the eSWT's UI thread which is referred as main thread. Although, from an eSWT developer perspective, main thread is eSWT's UI thread but it actually has nothing to do with the native UI resources. The implementation of LCDUI on the same platform also has a similar architecture. LCDUI is specified to be a thread-safe API so in LCDUI's case the second thread (that hides the native UI thread) is more or less a necessity where eSWT's second thread is a design decision.

This design, as with any design. comes with both positive and negative consequences. The main benefit of the two threaded solution is because the real UI is run by a thread that is not directly accessible for Java applications, it is not possible for a poorly developed application to freeze the UI and eventually get killed by the Symbian OS. However, this security comes with a performance penalty. A two thread design translates to a lot of thread switching and thread switching is costly. In theory, for every call that you make to UI components, even simple things such as setting the background color for a line makes a thread switch. In practice, however both eSWT and LCDUI tries to reduce the number of thread switches especially for primitive graphics drawing by introducing command buffers etc. in the implementation. eSWT buffers all GC calls that are possible to buffer during a paint event and passes them to the UI thread at the end of the event. LCDUI also does similar on paint callbacks.

When the new implementation of eSWT port for Qt started, it was decided that the performance penalty was too much to dismiss for the gained robustness. So eSWT port on Qt is designed and implemented to have a single thread that wraps the Qt's UI thread. As a consequence of the simplified design, the implementation ended up to be identical to any other SWT port. In fact,it borrows much of the code from SWT win32 port. I see that this contributed a big deal to the maturity of the Qt port. In the earlier testing we have also noticed some performance gains. it is really unfortunate that LCDUI implementation is not able to take advantage of a similar architecture because the thread safe nature of LCDUI forces the implementation to use two threads.

If you are an application developer using eSWT or LCDUI on Symbian platform this is probably some geeky extra information that you should not worry much about and the eSWT and LCDUI implementation will care about it for you. If you are interested in the actual implementation of the toolkit, you should keep this information at the corner of your mind.

Use ImageLoader with extra caution

2010-03-15T14:37:00.001-04:00

The ImageLoader class of eSWT and SWT is a utility class for loading and saving images. At a first glance, it is a very useful little utility class. Unfortunately, it is one piece of SWT/eSWT API that gives the implementation teams a performance headache. SWT is a well performing API because it delegates most of the work to the native services. eSWT implementation also follows this legacy and because they are meant to run on more resource constraint environments they take it a step further.

Unlike the rest of the SWT, the meat of the ImageLoader is actually implemented on Java, SWT packs Java implementations of all the image codecs that it supports. According to some, Java implementation is around 20 times slower when loading an image compared to an image loaded by native means. For the best image loading performance, it is recommended to use one of the Image constructors, which loads the images natively. This advice holds true for eSWT applications as well. Do not use the ImageLoader for loading images because it will not only be slower but will also consume more memory.

So why do even the eSWT implementations fail to optimize ImageLoader? ImageLoader has a misleading name. In practice ImageLoader has nothing to do with Image it actually loads and saves ImageData. While doing that it exposes the ImageData it loads or saves on a public field. This gives no choice to the implementation but to make the whole data available up front. Furthermore, ImageData also exposes all its fields and that also has to be initialized fully when created. So what happens when on a typical scenario of loading and using an image through ImageLoader? First, the whole ImageData is loaded into these fields. This reading and encoding is done on Java and is slower. Then this data is passed to the native toolkit which also doubles the amount of memory used for that image at least until the ImageData is released. Using Image constructors works around both defects, image is loaded and encoded natively and the data is not copied to Java fields limiting the memory usage.

One option for optimization is loading the ImageData through native code, but this actually triples the amount of memory used and copied around. The image data gets created first on the native code and then gets copied to Java and copied back to native to create the native image. As a result, this is not an option used by the SWT/eSWT implementations at least for now.

Eclipse eRCP 1.3 on Linux Qt

2009-09-09T08:05:00.001-04:00

eRCP team have been working day and night with eSWT port for Qt. We have resolved some of the immediate problems and integrated with the eRCP builds. An early access package for eRCP on Linux Qt now exists. You can download it form the usual eRCP downloads page. This is the very first attempt to create an eRCP package using our new Qt port, this means that it has problems. We want to fix them so please take time to report them.

Also under discussion, is creating similar eRCP distributions wherever Qt is present. However, we need help. We are short on people who can help with the packaging, testing and fixing stuff for other platforms. If you think you can help please drop a line to ercp-dev mailing list.

If eRCP is not your thing but you think that a Qt port for SWT would be great, that idea is still on the table looking for backers. Please use the ercp-dev mailing list again to express your interest to help. I know that it is odd to express interest for full SWT on eSWT mailing list but until SWT community picks up the idea this will have to do.

OpenVG on Eclipse eRCP

2009-08-20T07:43:00.001-04:00

I have posted earlier eRCP project is getting a Qt port for eSWT as a contribution from Nokia. The contribution is on its way and you should expect the first experimental eRCP builds on Linux soon. Qt announcement is an important one which enables that eRCP on more platforms. It also provides Eclipse community with a starting point for a full SWT port on Qt.

While the news of the Qt port is fresh, eRCP project received a new contribution for another UI technology. Microdoc is contributing Java bindings for OpenVG to eRCP project. OpenVG is an API designed for low level hardware accelerated 2D vector graphics. OpenVG is essentially a mobile device technology utilized mostly by cell phones and handhelds, therefore it is a good match for eRCP.

Contribution also includes samples for OpenVG. Once the contribution is blessed by the Eclipse legal process the team(with its new member from Microdoc) will work on it to integrate it with the existing eSWT ports and will create OSGi bundles for it.

What happend to eSWT port on Qt

2009-07-10T07:17:00.001-04:00

In case you are wondering what happened to Nokia's contribution of the eSWT implementation using Qt here is an update. If you are hearing about such a contribution for the first time, you can read the details in this earlier post.

The legal check for the contribution has been completed and we are now clear to check the code into CVS. However, we have a slight delay now. All the developers of the Nokia's eSWT team that have commit rights are on vacation (as illustrated by footage). Our original plan was to complete the contribution before the summer holiday's started but the legal check took longer than we have expected. Nevertheless, the code will be available in late August, and will start spreading the eSWT love to new platforms.

CSS support on Qt port of eSWT

2009-06-10T09:40:00.005-04:00

As I have blogged on my earlier post, we are replacing the eSWT implementation on Nokia S60 with a Qt based one. As part of the port we have experimented with some new cool features. One of them is the CSS styling support.
Here is a video of a demo that is showing the feature. Some of notable things on the demo are linear and circular gradient backgrounds and rounded corners on all widgets. Also styles actually set a top margin to some of the widgets and that works perfectly together with GridLayout used.

Of course no eSWT demo is complete without running the same on mobile. Here is the same example application running on Nokia S60 SDK.

The current state of the contribution is it is submitted to Eclipse for IP check. We are hoping to make the code available as soon as that completes. In the meanwhile, we are looking for individuals and companies who are willing to contribute to the effort to complete the implementation to SWT level APIs.

Comments Open for eSWT-LCDUI bridge API

2009-06-08T07:53:00.000-04:00

I have posted the draft API for using eSWT widgets with LCDUI on a bug report. This is one of the features that I have blogged about on my earlier post and it has been a desired feature for LCDUI developers on MIDP platforms since the day Nokia started shipping eSWT. The API has a similar structure to SWT-AWT bridge API and allows embedding of eSWT widgets into LCDUI components.
This API not only aims to provide LCDUI based applications a path to gradually move to eSWT but also enables the platform vendors to gradually implement eSWT APIs on their plarforms as it hides the details of eSWT.

Reflections of Symbian Foundation and Nokia S60 Java Runtime Roadmaps on eSWT

2009-06-07T04:06:00.002-04:00

I have been meaning to write about the future plans around eSWT for a long time. The recent announcements of Symbian Foundation roadmap and Nokia S60 Java Runtime roadmap has presented the perfect opportunity so here it is.

Let’s start with the major change. As stated on the Symbian roadmap, with Symbian^4 release, a Qt extension called Orbit will replace the existing Avkon UI library of the Symbian. Therefore, Nokia’s eSWT team had been working on an eSWT port using Qt for some time now. We now have full eSWT libraries implemented and running on several platforms including Linux, Maemo, Nokia S60 and win32 (probably runs on Mac too but it is never tested). We intend to make the implementation available as soon as we can on Eclipse eRCP CVS.

I know that there are many in Eclipse community interested on a SWT port on Qt. I have both good and bad news on that. The Qt implementation is done with a different approach compared to earlier eSWT ports. It is implemented in a very similar way to SWT ports rather than eSWT implementations. We have always considered that this implementation would be completed to extent full SWT APIs hence the existing code is suitable for extending to SWT. The bad news is, Nokia’s eSWT team will not do it. We would really like to complete it to SWT ourselves but our expertise and priority is on running eSWT on mobile devices. This does not mean we will not work with people who would like to contribute to a full SWT port. We also want to see a full SWT on Qt and will cooperate with contributors towards that goal. If you would like to contribute to such an effort please come forward and let us know.

A quick look at S60 Java Runtime roadmap reveals some of the features that are planned for eSWT. These features are going to be available on devices together with the Qt based eSWT. I will not go awfully detailed with all those features but rather introduce what is planned but expect detailed posts about them in the future here.

Improved MIDP interoperability: This work is divided into two areas. Improving the coding experience of MIDP developers by introducing new APIs. These APIs will hide some of the common tasks of developing eSWT based UIs by providing utilities.The second part enables the use of rich eSWT widget set within MIDP’s LCDUI components. This works in a similar way to SWT’s AWT bridge. Some of these APIs are drafted and will be open for comments this week on Eclipse bugzilla.

CSS based styling: E4 project is also introducing CSS styling to Eclipse as well. Current eSWT approach is different from e4, though. Current implementation is providing widget level CSS styling via the method Widget.setStyle(String css). I will be posting a demo video and more information about this. Stay tuned.

Animations API: At the moment, this is an early implementation of the SWT animation APIs drafted as part of e4 project. These are implemented using the Qt’s new Animation Framework.

Multi-touch and gestures: No mobile UI toolkit is complete without these nowadays. The details on these are sketchy at the moment. We are investigating several platforms and APIs to come up with an API that can be implemented on all platforms easily.

If you are willing to participate on any of the work that is happening around this new eSWT platform or any of the new APIs. You can contact and become part of the developer community from the eRCP mailing list.